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ERROR MESSAGING METHOD IN HTTP BASED 
COMMUNICATION SYSTEMS. 



TECHNICAL FIELD 



ERROR MESSAGING METHOD IN HTTP BASED COMMUNICATION SYSTEMS 

The present invention relates to message handling in communication 
networks and in particular to error messaging for communication based on 
the Hypertext Transfer Protocol (HTTP). 



Today, practically all web servers, clients and related web applications talk 
to each other through HTTP. The communication is based on HTTP requests 
and responses between clients and servers, for which HTTP defines a request 
response protocol. Every time a client sends an HTTP request, the web server 
returns a MIME (Multipurpose Internet Mail Extensions) header. The steirt 
line of the response reads: 

<version> <status code> <reason phrase> 

The version part refers to the version of HTTP used for the message. The 
status code is a three-digit code number roughly indicating what happened 
during the request. Status codes are grouped into general classes, which are 
described by the first digit. For example, codes on the format 2XX means 
^success**, whereas 4XX and 5XX codes indicate ''client error" and "server 
error", respectively. The reason phrase^ finally, is a human readable version 
of the code number, the features of which will be described below. The 
standard HTTP response to a successfxil GETT request is: 



BACKGROUND 



HTTP/ 1.0 200 OK 



The above line is typically followed by further header information, such as 
content type and length, and then the requested document. 
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A commonly used prior-art communication network comprises a web server 
commimicating with a client terminal via a proxy server (generally referred to 
as ''proxjr''). The proxy shuffles HTTP messages back and forth between the 
server and client. More specifically, the proxy conveys each request, which is 
5 based on HTTP or on the Wireless Session Protocol (WSP), from the wireless 
client to the web server and each subsequent HTTP response from the web 
server to the client. The start line of the response passes the proxy 
unchanged and the end-user receives a response message directly 
corresponding to the response sent from the web server- 

10 

Now assume that the server encounters an error and reports that in the 
HTTP response. For such a case (HEAD requests excepted) the HTTP protocol 
states that the server ^should include an entity containing an explanation of 
the error situation^ in the response ("Hypertext Transfer Protocol - 

a 

15 HTTP/1.1'', RFC 2616, R. Fielding et al., June 1999). Furthermore, user 
agents should display any included entity to the user^. This means that 
there may — or may not — be an explanation entity, i.e. a reason phrase, 
incorporated in the response message. Furthermore, even when there is a 
reason phrase it is not certain that it will be presented to the end-user. 

20 Sometimes only the error code is displayed. The provider of the requested 
service, e.g. a mobile operator, cannot possibly know what will happen in a 
particTilar error situation. 

Moreover, even if a reason phrase is shown, it may reflect the actual error 
25 situation very badly or even erroneous. The HTTP specification does not 
provide any guidance on the exact text for reason phrases, which are 
therefore rather arbitrary. Consequently, the end-user might get the wrong 
impression of the service provider, which is a veiy serious problem since it 
reduces the value of the service in the eyes of the user. 

30 

Accordingly, conventional hsmdling of HTTP error messages is far from 
satisfactory and there is a considerable need for an improved error 
messaging method. 
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SUMMARY 

general object of the present invention is to provide improved error 
handling in HTTP communication systems. A more specific object is to 
achieve reliable and informative error messages for client-server 
communication through an intermediate device, 

rhese objects are achieved in accordance with the atta.ched claims. 

Briefly, the method of the present invention utilizes the intermediate device 
interconnecting a wireless client terminal and a web server to achieve control 
Df error messages sent from the server. The error status code sent from the 
server is transformed into an informative error description message 
ncluding an extended error description text as well as a new status code. 
The new status code is preferably chosen such that it enforces display of the 
2rror description text. In this way, it is possible to control what message an 
md-user will receive in response to an unsuccessful request and also to 
^arantee that the message is actually displayed at the client terminal. The 
nvention is applicable on HTTP based communication and preferably 
mplemented in a proxy server through an error information table providing 
•esource-location dependent error description messages. 

n accordance with another aspect of the invention there is provided a proxy 
jerver with error messaging means. Error messaging means for Multimedia 
vlessaging Service (MMS) communication is also provided. 



wo 2004/084524 PCT/SE2002/002332 

4 

BRIEF DESCRIPTION OF THE DRAWINGS 

The invention, together with fxirther objects and advantages thereof, may best 
be landerstood by making reference to the following description taken together 
with the accompanying drawings, in which: 

Fig. 1 is a schematic overview of an exemplary network for communication 
between wireless clients and a web server; 

Fig. 2 is a schematic block diagram illustrating conventional error 
messaging upon client-server communication through an 
intermediate device; 

Fig. 3 is a schematic block diagram illustrating conventional error 
messaging for a system with an external web server; 

Fig. 4 is a schematic block diagram illustrating conventional error 
messaging for MMS communication; 

Fig. 5 is a schematic block diagram of an examplary embodiment of an 
error messaging system according to the present invention; 

Fig. 6 illustrates error message retrieval according to an examplaiy 
embodiment of the present invention; 

Fig. 7 is a schematic block diagram of an examplary embodiment of an 
error messaging system for MMS communication according to the 
present invention; 

Fig. 8 is a schematic block diagram of another examplary embodiment of 
an error messaging system for MMS commxonication according to the 
present invention; and 
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Tig. 9 is a flow chart of an exemplary embodiment of an error messaging 
method according to the present invention. 



DETAILED DESCRIPTION 

Phroughout the drawings the same reference numbers are used for similar 
>r corresponding elements. 



^'ig. 1 is a schematic overview of an exemplary network for commianication 
jetween wireless clients and a web server, A communication system 
:omprising a number of wireless client terminals 10-1, 10-2, 10-3, such as 
nobile phones, pagers and laptops, on one side and a web server 30 on the 
)ther is shown. The system further includes a proxy server 20, an 
ntermediate device that forms a bridge between the mobile network 15 and 
he services on the Internet 25. The proxy 20 may for instance also perform 
nessage filtering and/ or provide security solutions and other services. In 
practice, most commimication systems comprise multiple proxies and 
servers arranged in a more complex network than in the basic example of 
^ig. 1. 

iis outlined in the background section, the error information that an end- 
iser receives upon client-server communication through an intermediate 
levice is generally inadequate. The situation is illustrated in Fig, 2, which is 
L schematic block diagram of conventional error messaging. A wireless client 
erminal 10 is via a proxy server 20 connected to a web server 30. The 
Tireless client 10 sends a GET request to the proxy 20, which conveys the 
nessage to the web server 30. As indicated in the drawing, the client 10 and 
)roxy 20 talk to each other through either the WSP or the HTTP protocol. 
VSP is at present the most common language for this type of 
:ommunication. However, the communication between the proxy 20 and web 
;erver 30 is always HTTP based. The web server 30 of Fig. 2 encounters an 
:rror when processing the request and sends a response with, for example, 
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he status code 500 for "server error" to the proxy 20, which forwards the 
esponse start line unchanged to the client terminal 10. The response may or 
aay not contain the rather limited reason-phrase described in the 
background section, which may or may not be displayed at the client 
5 erminal 10- 

t is evident from Fig. 2 that the end-user sees what the web server wants it 
3 see in terms of error information. This is particularly problematic for 
ituations like the one in Fig. 3, where an external web server is employed. 

10 *he web server 30 is located outside the control range 40 of the mobile 
perator, e.g. on the Internet. An error message, in this example with the 
rror status code 400, is sent from the external web server 30, passes the 
roxy 20, and is received at the client terminal 10, At best the end-user sees 
meager reason phrase, but he may also be left with only the rather 

15 icomprehensible error status code, and it is likely that he gets the 
npression that the mobile operator has a poor service quality. The mobile 
perator cannot affect the existence and wording of a possible reason phrase. 

roblems of the above-described type also arise in relation to services that 
10 re operated by the mobile operator, for example MMS. Such a situation is 
isclosed in Fig. 4, which is a schematic block diagram of conventional error 
lessaging for MMS communication. The elements of Fig. 4 correspond 
trectly to those of Fig. 3, except for the server 30, which in this case is a 
[MS center (MMSC). Assume for instance that the end-user has received 
25 [MS messages that are stored in the MMSC 30, and that the notifications 
lereof for some reason do not reach the end-user. His mobile phone 10 may 
•r example be turned off. After a certain period of time the MMS messages 
ill be erased from the MMSC 30 but when the mobile phone 10 becomes 
/ailable again, the end-user still receives notifications that there exists 
JO :mS messages in the MMSC 30. As he tries to collect them, an error 
lessage will be displayed. This error message is an HTTP response with an 
Tor status code, which passes the proxy 20 unchanged like in the above- 
iscribed cases. There is no way of informing the end-user that the 
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messages have been erased. Naturally, this may lead to bad perception of the 
offered service, in this case MMS, and eventually to dissatisfied customers. 

The present invention eliminates the above problems by taking advantage of 
the fact that the mobile operator generally controls the proxy in the above 
situations. Instead of just passing on an error status code from the web 
server to the client terminal, the proxy of the invention transforms the status 
::ode into an error description message including two parts that together 
result in a most reliable and advantageous error message handling. This will 
now be described in detail with reference to Figs. 5 and 6. 

Tig. 5 is a schematic block diagram of an examplaiy embodiment of an error 
messaging system according to the invention. As before, the request and 
response messages between the wireless client terminal 10 and the web 
server 30 passes an intermediate device 20, such as a proxy server or a 
gateway (here illustrated as the former). The wireless client terminal 10 is in 
he communication system in accordance with the invention implemented as 
my suitable kind of wireless device, including mobile phones, laptops and 
personal digital assistants. The wireless client terminal 10 and the 
ntermediate device 20 may either speak WSP or HTTP to each other, 
dthough the currently most preferred embodiment of the invention uses 
VSP for client-proxy commxmication. The intermediate device 20 of the 
nvention may be a WSP proxy/ Wireless Application Protocol (WAP) gateway 
)r an HTTP proxy. It could for instance with advantage be the Mobile 
ntemet Enabling Proxy 1.0 available from Ericsson. The communication 
between the intermediate device 20 and the web server 30 is governed by the 
ITTP protocol. The web server 30 thus processes HTTP requests and serves 
esponses and is also referred to as an HTTP server. The server used with the 
nvention may implement a wide range of functionalities and can e.g. be a 
AMSC. 

im referring to Fig. 5, the client terminal 10 sends a GET request asking for 
L resource on a location specified by the Uniform Resource Locator (URL) to 
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the proxy 20, which forwards the HTTP message to the requested web server 
30 in the conventional way. When an error is encountered the server 30 
outputs a first HTTP error status code (500 in the example of Fig. 5) to the 
proxy 20. According to the invention, the proxy 20 then transforms this first 
error status code into an error description message comprising an error 
description text 24 and a second status code (200 in the example of Fig. 5) 
before the message is transmitted to the client terminal 10. 

The error description text 24 is a text of arbitrary length that explains the 
srfbr situation to the end-user. It is preferably implemented as a page of the 
SVireless Markup Language (WML) or the Hypertext Markup Language 
HTML). The error description text is thus not to be confused with the 
optional and very limited reason phrase that, as mentioned in the 
Dackground section, sometimes accompanies the error status code in the 
"start line of an HTTP message. 

The second status code serves to ensure that the error description text 24 is 
iisplayed at the client terminal 10. Preferably, an HTTP status code of the 
?XX format, such as the 200 code, forms the second status code of the 
nvention, since these codes mean "success" and thus imply that an 
ittached document is always shown. Hence, an error description page sent 
ogether with the 200 status code is guaranteed to be presented to the end- 
iser. 

'he present invention thus uses a status code which does not have to 
adicate an error but could instead constitute a positive response to enforce 
lisplay of the desired error description text at the client terminal. In this 
/ay, the mobile operator controls both the actual description text of the 
rror message as well as the presentation thereof and can achieve 
ompulsoiy display of any desired explanation text to the end-user. 

he error message transformation is preferably implemented by means of an 
rror information table 22. As illustrated in Fig. 6, the first error status code 
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and preferably also the URL of the HTTP request is input to the table 22. 
Based on this input parameter information, the second status code and the 
error page with the error description text 24 are provided. It is preferred that 
the URL is input to the error information table 22, since that enables 
resource-location dependent error description messages to be output. 

The error information table 22 is preferably implemented in the proxy 
software. However, embodiments where the proxy calls upon an external error 
information table also lie within the scope of the invention. 

Table 1 outlines the structure of an error information table in accordance 
with a preferred embodiment of the invention. It contains a number of 
example cases, where input parameters in the form of a first error status 
code and the server of the URL are transformed into an error description 
message. The error description message is based on output parsimeters 
comprising a second status code and an error page with an error description 
text. The language of each error page is preferably defined in the table. 



Table 1 



1st code 


URL 


2»<* code 


Error page 


400 


www.operator.com 


200 


HTML page with error 
description text TO 


404 


www.operatorMMSC.com 


200 


new MMS message with 
error description text 


500 


external web server SI 


200 


WML page with error 
description text Tl 


500 


external web server S2 


200 


HTML page with error 
description text T2 


500 


external web server S3 


200 


WML page with error 
description text T3 


501 


operator web server 


501 




502 


external web server S4 


200 


HTML page with error 
description text T4 



Consider for example a request with a URL that points to a particular web 
server 81 located outside the mobile operator control. Such a request would, 
when being subject to an HTTP error with status code 500, according to 
rable 1 result in that the proxy sends a WML page with a suitable error 
description text Tl together with the new status code 200 to the client 
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terminal. The status code 200 for "success'' guarantees that the error 
description text is presented to the end-user. 

Table 1 implements the mentioned preferred usage of the URL service- 
location information by the proxy to provide resource-location dependent 
error messages. One important distinction hereby is between external web 
servers and servers within the control range of the mobile operator. 
Sometimes an error code associated with an operator web server may not 
even be considered to motivate an extended error description text, but rather 
just pass the proxy unchanged (see the example with status code 501). 
Furthermore, different external web servers are typically treated differentiy. 
The cases with server URL SI, S2 and S3, for example, all have the same 
input status code (500). Nevertheless, different error description texts T'l, T2 
and T3 are output, depending on the respective service location. These, case- 
specific error description texts evidentiy contain more detailed explanations 
of respective error situation than would otherwise be possible. 

One example in Table 1 concerns the case where the web server is an MMSC 
controlled by the mobile operator. This is also illustrated by Fig. 7, which is 
a schematic block diagram of an examplary error messaging system for MMS 
communication according to the invention. The error description message 
aow preferably comprises a new MMS message 24 with the desired error 
description text. In the case of deleted MMS messages (described with 
reference to Fig. 4), the error description text would typically inform the end- 
aser that the messages have been removed and preferably also include an 
explanation thereto. The MMS package 24 is sent to the MMS browser of the 
:lient terminal 10, where it is converted into a WML or HTML page enabling 
iisplay of the error description text. 

The first status code 404 sent from the MMSC 30 in Fig. 7 is an example. It 
:ould be any HTTP error status code, such as e.g. another 4XX code. 
Similarly, any 2XX code, or other status code associated with compulsory 
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document presentation, may replace the second status code in a preferred 
MMS communication system. 

In Fig. 7 the MMS error message 24 is generated and transmitted from the 
5 proxy 20. Although this is the preferred implementation, there may be 
situations where the new MMS message is instead generated by the MMSC, 
as illustrated in Fig. 8. The error description text is then, possibly together 
with one or several images, packed in the MMSC 30 to form the new MMS 
message 24 according to the MMS standard. The error description text can 

iO be implemented through either a text document or an image document in 
the MMS message 24. The new MMS message 24 with the error description 
text is sent from the MMSC 30 together with an HTTP status code for 
success, e.g. the 200 code. Since the proxy 20 now believes that the GE)T 
request was successful, it just forwards the error message to the client 

15 terminal 10. As before, the MMS package 24 is sent to the MMS browser of 
the client terminal 10, where it is converted into a WML or HTML page 
enabling display of the error description text. 

ft^lthough the illustrated examples concern the request method GEJT, it 
20 should be understood that the invention is applicable to other HTTP request 
methods as well, including the POST method. A skilled person also realizes 
that the error code numbers herein are examples and that the invention can 
be used for other HTTP error codes. 

25 F'ig. 9 is a flow chart of an examplaiy embodiment of a preferred method of 
handling error messages in accordance with the invention. The procedure is 
iiitiated upon an HTTP request from a wireless client terminal. In a step SI, 
1 first status code, which is an HTTP error status code from a server, is 
received at an intermediate device, e.g. a proxy. The first status code is in a 

30 step S2 transformed by the intermediate device into an error description 
nessage containing an error description text as well as a second status code. 
Step S2 preferably comprises extracting the error description message from 
^ m error information table in response to input parameter information 
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ncluding the first status code and the URL server. Thereby, resoiarce- 
.ocation dependent error description messages are obtained. In a step S3, 
lie intermediate device transmits the error description message comprising 
1 WML page, an HTML page or an MMS message carrying the error 
5 iescription text to the client terminal. Display of the error description text to 
lie end-user is enforced by the nature of the second status code in a final 
step S4. The procedure thus achieves guaranteed presentation of any desired 
OTor description text. 

10 \lthough the invention has been described with reference to specific 
Uustrated embodiments, it should be emphasized that it also covers 
jqxaivalents to the disclosed features, as well as modifications and variants 
)bvious to a man skilled in the art. Thus, the scope of the invention is only 
imited by the enclosed claims. 
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